Maintaining internet protocol security tunnels

ABSTRACT

A network device identifies an Internet Protocol Security (IPsec) tunnel that connects the network device to a remote device and determines that dead peer detection (DPD) is enabled at the network device. The network device receives a first DPD request message from the remote device via the IPsec tunnel, and sends a first DPD response message to the remote device via the IPsec tunnel. The network device determines that a workload of the network device satisfies a threshold amount, and sends one or more encapsulating security payload (ESP) packets that include traffic flow confidentiality (TFC) payload data to the remote device via the IPsec tunnel. The network device determines that the workload of the network device does not satisfy the threshold amount. The network device receives a second DPD request message from the remote device and sends a second DPD response message to the remote device via the IPsec tunnel.

BACKGROUND

Dead Peer Detection (DPD) may be used by an Internet Key Exchange (IKE)network device to detect a dead IKE peer. DPD also may be used toreclaim resources of the IKE network device in case a dead IKE peer isfound.

SUMMARY

According to some implementations, a method may include identifying, bya device, an Internet Protocol Security (IPsec) tunnel that connects thedevice to a remote device, and determining, by the device, that deadpeer detection (DPD) is enabled at the device. The method may includereceiving, by the device, a first DPD request message from the remotedevice via the IPsec tunnel, and sending, by the device, a first DPDresponse message to the remote device via the IPsec tunnel. The methodmay include determining, by the device, that a workload of the devicesatisfies a threshold amount, and sending, by the device and based ondetermining that the workload of the device satisfies the thresholdamount, one or more encapsulating security payload (ESP) packets thatinclude traffic flow confidentiality (TFC) payload data to the remotedevice via the IPsec tunnel. The method may include determining, by thedevice and after sending the one or more ESP packets, that the workloadof the device does not satisfy the threshold amount. The method mayinclude receiving, by the device, a second DPD request message from theremote device via the IPsec tunnel, and sending, by the device, a secondDPD response message to the remote device via the IPsec tunnel.

According to some implementations, a device may include one or morememories, and one or more processors to identify an Internet ProtocolSecurity (IPsec) tunnel that connects the device to a remote device, andto determine that a dead peer detection (DPD) process is enabled at thedevice. The one or more processors may identify a recurring intervalassociated with the DPD process, and maintain the IPsec tunnel, wherein,when maintaining the IPsec tunnel, the one or more processors are tolisten for traffic on the IPsec tunnel during the recurring interval,determine that there was no traffic on the IPsec tunnel during therecurring interval, and send, based on determining that there is notraffic on the IPsec tunnel during the recurring interval, one or moreencapsulating security payload (ESP) packets that include traffic flowconfidentiality (TFC) payload data to the remote device via the IPsectunnel.

According to some implementations, a non-transitory computer-readablemedium may store instructions that include one or more instructionsthat, when executed by one or more processors of a device, cause the oneor more processors to recognize an Internet Protocol Security (IPsec)tunnel that connects the device to a remote device, and to determinethat the device uses dead peer detection (DPD). The one or moreinstructions may cause the one or more processors to determine a triggerinterval associated with DPD at the device, to determine that a workloadof the device satisfies a first threshold amount, and to increase, basedon determining that the workload of the device satisfies the firstthreshold amount, the trigger interval. The one or more instructions maycause the one or more processors to send, after increasing the triggerinterval, a first DPD request message to the remote device via the IPsectunnel based on the trigger interval, and to receive a first DPDresponse message from the remote device via the IPsec tunnel based onsending the first DPD request message. The one or more instructions maycause the one or more processors to determine that the workload of thedevice satisfies a second threshold amount, and to decrease, based ondetermining that the workload of the device satisfies the secondthreshold amount, the trigger interval. The one or more instructions maycause the one or more processors to send, after decreasing the triggerinterval, a second DPD request message to the remote device via theIPsec tunnel based on the trigger interval, and to receive a second DPDresponse message from the remote device via the IPsec tunnel based onsending the second DPD request message.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1F are diagrams of example implementations described herein.

FIG. 2 is a diagram of an example environment in which systems and/ormethods, described herein, may be implemented.

FIG. 3 is a diagram of example components of one or more devices of FIG.2.

FIG. 4 is a flow chart of an example process for maintaining InternetProtocol Security tunnels.

FIG. 5 is a flow chart of an example process for maintaining InternetProtocol Security tunnels.

FIG. 6 is a flow chart of an example process for maintaining InternetProtocol Security tunnels.

DETAILED DESCRIPTION

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

Dead Peer Detection (DPD) may be used by an Internet Key Exchange (IKE)network device to detect situations where connectivity between the IKEnetwork device and an IKE peer goes down, such as when the IKE peer goesoffline (e.g., the IKE peer is dead). The IKE network device may use DPDto generate and send an encrypted IKE message (e.g., a DPD requestmessage) to the IKE peer and determine the state of the IKE peer (e.g.,the IKE peer is up or down, alive or dead, and/or the like) based onwhether the IKE network device receives an encrypted IKE message (e.g.,a DPD response message) from the IKE peer acknowledging the IKE networkdevice's message. If the IKE network device determines that the IKE peeris dead, the IKE network device may reclaim resources of the IKE networkdevice that were dedicated to connecting the IKE network device to thedead IKE peer. In this way, DPD may ensure that resources of the IKEnetwork device are dedicated to connections with only live IKE peers.

However, in some cases, the IKE network device and/or the IKE peer maybe overloaded, which may cause a delay in sending and/or receiving DPDmessages. This may result in the IKE network device erroneouslydetermining that the IKE peer is dead and then reclaiming resources thatshould be maintained, such as breaking down an Internet ProtocolSecurity (IPsec) tunnel that connects the IKE network device to the IKEpeer. In turn, this may overload the IKE network device and IKE peereven more, because resources will have to be dedicated to connecting theIKE network device to the IKE peer again, such as constructing a newIPsec tunnel. This may create a cycle of reclaiming and dedicatingresources that may choke the processing functions of the IKE networkdevice and the IKE peer. Similarly, this may cause IPsec tunnel flapping(e.g., an IPsec tunnel continuously being created and destroyed) or mayresult in delayed establishment of IPsec tunnels.

Some implementations described herein provide a network device that iscapable of modifying DPD at the network device to maintain an IPsectunnel with a peer network device while reducing a workload ofprocessing resources associated with the network device. In someimplementations, the network device may determine that the workload ofthe network device satisfies a threshold amount, generate one or moreencapsulating security payload (ESP) packets (e.g., one or more ESPpackets with traffic flow confidentiality (TFC) payload data), and sendthe one or more ESP packets to the network device via the IPsec tunnel.In this way, the network device and the peer network device may not needto exchange DPD messages because the network device creates traffic onthe IPsec tunnel. In some implementations, the network device maydetermine that the workload of the network device satisfies a thresholdamount and modify an interval associated with DPD at the network deviceto exchange DPD messages with the network device according to theinterval. In this way, the network device may not need to send and/orreceive as many DPD messages while the workload of the network device ishigh, which may aid in reducing the workload of the network device. Insome implementations, the network device may disable DPD at the networkdevice, generate one or more ESP packets (e.g., one or more ESP packetswith TFC payload data), and send the one or more ESP packets to thenetwork device via the IPsec tunnel to maintain traffic on the IPsectunnel and prevent the peer network device from sending DPD requestmessages to the network device. In this way, the network device may notneed to dedicate processing resources to DPD while the network devicemaintains the IPsec tunnel by generating and sending the one or more ESPpackets.

In this way, implementations described herein enable the network deviceand the network device to stay connected via the IPsec tunnel even whenthe network device or the network device is overloaded. In this way,time is not wasted reinitiating IKE and IPsec negotiations between thenetwork device and the network device. Moreover, in this way, theworkload of the network device may be reduced because fewer processorand/or memory resources of the network device would be used relative totraditional DPD.

In this way, a process for maintaining IPsec tunnels is automated andthe network device may maintain numerous (e.g., hundreds, thousands,millions, and/or the like) IPsec tunnels at the same time. This mayimprove speed and efficiency of the process and conserve computingresources (e.g., processor resources, memory resources, and/or the like)of the network device. Furthermore, automating the process formaintaining IPsec tunnels conserves computing resources (e.g., processorresources, memory resources, and/or the like) that would otherwise bewasted using a traditional DPD process.

FIGS. 1A-1F are diagrams of example implementations 100 describedherein. As shown in FIG. 1A, implementation 100 may include a firstnetwork device (shown as network device A) and a second network device(shown as network device B).

The first network device and/or the second network device may includevarious types of network devices, such as a router, a gateway, a switch,a bridge, a wireless access point, a base station, a firewall, and/orthe like. The first network device and the second network device may beincluded in a network, such as a cellular network, a local area network(LAN), a core network, an access network, a wide area network (WAN) suchas the Internet, a cloud network, and/or the like. In someimplementations, a neighbor device (not shown) may be communicativelyconnected with the first network device and/or the second network devicethrough another neighbor device. In some implementations, a neighbordevice may be communicatively connected directly with the first networkdevice and/or the second network device (i.e., where there is no otherneighbor device in the communications path between the neighbor deviceand the first network device and/or the second network device).

The first network device and/or the second network device may includevarious communication planes, such as a data plane, a control plane,and/or the like. The data plane of a network device may generate,receive, process, and/or transmit data plane packets. A data planepacket may be a packet that is originated in the control plane of thenetwork device (i.e., generated by the network device) or terminated inthe control plane of the network device (i.e., the network device is thedestination of the packet). A data plane packet may be a packet thattravels through the network device. The data plane may receive a dataplane packet, perform a lookup in a forwarding information base (FIB) onthe network device to identify forwarding information associated withthe data plane packet (e.g., information identifying a destination ofthe data packet, information identifying a next hop in a route to thedestination, and/or the like), and transmit the data plane packet to thenext hop based on the forwarding information. The network device mayhave processing and/or memory resources that are dedicated to performingthe functions of the data plane.

The control plane of the network device may generate, receive, process,and/or transmit control plane packets. A control plane packet may be apacket that originated in the control plane of the network device (i.e.,generated by the network device) or terminated in the control plane ofthe network device (i.e., the network device is the destination of thepacket). In some implementations, a control plane packet may begenerated at a neighbor device, and the network device may forward thecontrol plane packet to another neighbor device. The control plane mayinclude a control plane, a FIB, a FIB cache associated with the FIB,and/or other elements.

The control plane may perform various functions, such as populating theFIB with forwarding information, maintaining the forwarding informationstored in the FIB (e.g., updating the forwarding information stored inthe FIB, removing forwarding information from the FIB, and/or the like),establishing and/or terminating a control plane session between thecontrol plane and another component in the network device and/or betweenthe control plane and a device external to the network device, managingthe data plane, populating and maintaining the FIB cache for a controlplane session, encrypting and decrypting traffic to and from the controlplane, establishing and/or tearing down a tunnel with a device externalto the network device (e.g., an Internet Protocol Security (IPsec)tunnel), and/or the like. The network device may have processing and/ormemory resources that are dedicated to performing the functions of thecontrol plane.

In some implementations, the first network device and the second networkdevice may be Internet Key Exchange (IKE) network devices. In someimplementations, the control plane of the first network device and thesecond network device, respectively, runs an IKE server that handles IKEexchanges (e.g., information communicated on an IPsec tunnel). In someimplementations, the first network device and the second network deviceare peer IKE network devices. In some implementations, the first networkdevice may be connected to the second network device. In someimplementations, the first network device may be connected to the secondnetwork via an IPsec tunnel.

As shown by reference number 102, the first network device may identifyand/or recognize an IPsec tunnel that connects the first network deviceto the second network device. In some implementations, the first networkdevice may communicate with the second network device via the IPsectunnel. For example, the first network device may send packets, such asUser Datagram Protocol (UDP) packets, to the second network via theIPsec tunnel.

As shown in FIG. 1B and by reference number 104, the first networkdevice may determine that Dead Peer Detection (DPD) and/or a DPD processis enabled at the first network device. In some implementations, thefirst network device may use DPD when the IPsec tunnel is idle (e.g.,the first network device is not receiving packets, information,messages, and/or the like from the second network device and/or thefirst network device is not transmitting packets, information, messages,and/or the like to the second network device). The IPsec tunnel may beidle because the IPsec tunnel may be experiencing routing issues, thefirst network device and/or second network device may be busy, the firstnetwork device and/or the second network device may be offline, and/orthe like.

In some implementations, DPD allows the first network device and thesecond network device to exchange DPD messages to prove liveliness ofthe second network device to the first network device, and vice versa.For example, as shown by reference number 106, the first network device,via the IPsec tunnel, may generate and send a DPD request message to thesecond network device and receive a DPD response message from the secondnetwork device. Based on this exchange, the first network device maydetermine that second network device is alive and that the IPsec tunnelshould be maintained. As a further example, as shown by reference number108, the first network device, via the IPsec tunnel, may receive a DPDrequest message from the second network device and generate and send aDPD response message to the second network device. Based on thisexchange, the first network device may prove that the first networkdevice is alive to the second network device. Similarly, because thefirst network device received the DPD request message from the secondnetwork device, the first network device may determine that the secondnetwork device is alive and that the IPsec tunnel should be maintained.

In some implementations, the first network device and the second networkdevice communicate the DPD messages via the control plane of the firstnetwork device and the control plane of the second network device,respectively. For example, the first network device generates and sendsa DPD request message to the second network device via the control planeof the first network device and receives a DPD response message from thesecond network device via the control plane of the first network device.As an additional example, the first network device receives a DPDrequest message from the second network device via the control plane ofthe first network device and generates and sends a DPD response messageto the second network device via the control plane of the first networkdevice.

In some implementations, an interval (e.g., a recurring interval, atrigger interval, a periodic interval, and/or the like) may beassociated with DPD and/or the DPD process at the first network device.The interval may specify an amount of time (e.g., 1 second, 5 seconds,50 seconds, 5 minutes, and/or the like) that the first network devicewaits to generate and send a DPD request message after detectingidleness of the IPsec tunnel and/or an amount of time (e.g., 1 second, 5seconds, 50 seconds, 5 minutes, and/or the like) that the first networkdevice waits to respond to a DPD request message.

In some implementations, the first network device may use differentoptions to maintain the IPsec tunnel and minimize the use of the firstnetwork device's control plane resources. In a first option, as shown inFIG. 1C, where the first network device is stressed (e.g., the controlplane of the first network device has a high utilization rate, a highworkload, and/or the like), the first network device may generate one ormore encapsulating security payload (ESP) packets (e.g., one or more ESPpackets with traffic flow confidentiality (TFC) payload data) and sendthe one or more ESP packets from the data plane of the first networkdevice to the second network device via the IPsec tunnel. In this way,the first network device does not have to devote control planeprocessing resources to exchange DPD messages while the first networkdevice is stressed, which may reduce the stress on the first networkdevice.

In some implementations, the first network device may exchange DPDmessages via the IPsec tunnel until a workload of the first networkdevice satisfies a threshold amount. As shown by reference number 110,the first network device may determine that the workload of the firstnetwork device satisfies the threshold amount. For example, the firstnetwork device may determine that the processing resources of the firstnetwork device are being utilized at a level (e.g., a rate ofutilization, such as 70%) that satisfies a threshold amount (e.g., arate of utilization that must be exceeded, such as 50%). In someimplementations, the workload of the first network device indicates autilization of processing resources associated with the control plane ofthe first network device. For example, the first network device maydetermine that the workload of the first network device satisfies thethreshold amount by determining that the utilization of processingresources associated with the control plane of the first network devicesatisfies the threshold amount. In some implementations, the firstnetwork device may disable DPD at the first network device (e.g., thefirst network device stops exchanging DPD messages) after the firstnetwork device determines that the workload of the first network devicesatisfies the threshold amount. In some implementations, the firstnetwork device may disable DPD at the first network device until thefirst network device determines that the workload of the first networkdevice no longer satisfies the threshold amount.

As shown by reference number 112, the first network device may listenfor traffic on the IPsec tunnel. In some implementations, the firstnetwork device may monitor the IPsec tunnel to determine whether apacket is sent or received via the IPsec tunnel. In someimplementations, the first network device may monitor the IPsec tunnelto determine whether a packet is sent or received via the IPsec tunnelduring the interval. In some implementations, the first network devicemay determine whether the first network device sent or receivedinformation via the IPsec tunnel during the interval. In someimplementations, the first network device may determine whether thefirst network device sends one or more outgoing messages to the secondnetwork device via the IPsec tunnel during the interval and/or the firstnetwork device receives one or more incoming messages from the secondnetwork device via the IPsec tunnel during the interval.

In some implementations, based on listening for traffic on the IPsectunnel, the first network device may determine that the IPsec tunnel isidle. In some implementations, the first network device may determinethere is no traffic on the IPsec tunnel. In some implementations, thefirst network device may determine that there has been no traffic on theIPsec tunnel for the interval.

As shown by reference number 114, as an alternative to generating andsending a DPD request message from the control plane of the firstnetwork device to the second network device via the IPsec tunnel, thefirst network device may generate one or ESP packets (e.g., one or moreESP packets with TFC payload data) and send the one or more ESP packetsfrom the data plane of the first network device to the second networkdevice via the IPsec tunnel. In this way, the first network devicemaintains traffic on the IPsec tunnel by using control plane processingresources instead of control plane processing resources. For example,the first network device may generate and send, based on determiningthat the workload of the first network device satisfies the thresholdamount, the one or more ESP packets to the second network device via theIPsec tunnel. In some implementations, the first network device, via thedata plane of the first network device, may generate and send the one ormore ESP packets to the second network device. In this way, because thefirst network device IPsec tunnel is no longer idle, the IPsec tunnel ismaintained while the first network device generates and sends the one ormore ESP packets to the second network device via the IPsec tunnel.

In some implementations, the first network device may determine a ratefor generating and sending the one or more ESP packets. In someimplementations, the rate may ensure that at least one ESP packet of theone or more ESP packets is generated and sent during the interval. Insome implementations, the first network device may generate and send theone or more ESP packets to the second network device via the IPsectunnel at the rate. In this way, the first network device generates andsends the one or more ESP packets to the second network device via theIPsec tunnel on a schedule that ensures that the second network devicemay determine that the first network device is alive and thereforemaintain the IPsec tunnel.

As shown by reference number 116, the first network device may determinethat the workload of the first network device no longer satisfies thethreshold amount. In some implementations, the first network device maydetermine, after generating and sending the one or more ESP packets,that the workload of the device does not satisfy the threshold amount(e.g., the utilization rate of the first network device's resources doesnot exceed the rate of utilization that must be exceeded). As a result,the first network device may stop generating and sending the one or moreESP packets. In some implementations, the first network device enablesDPD at the first network device (e.g., the first network device startsexchanging DPD messages again) after the first network device determinesthat the workload of the first network device does not satisfy thethreshold amount.

In a second option, as shown in FIG. 1D and by reference number 118, thefirst network device may determine that a workload of the first networkdevice satisfies a first threshold amount in a similar manner to thatdescribed herein in relation to FIG. 1C. In some implementations, thefirst network device may increase, based on determining that theworkload of the first network device satisfies the first thresholdamount, the interval (e.g., the first network device may increase theamount of time associated with the interval, such as from 5 seconds to10 seconds, from 20 seconds to 1 minute, from 2 minutes to 5 minutes,and/or the like). By increasing the interval, the network device may notneed to send and/or receive as many DPD messages while the workload ofthe network device is high, which may aid in reducing the workload ofthe network device.

As shown by reference number 120, the first network device may sendand/or receive DPD messages according to the interval (e.g., the firstnetwork device may exchange DPD messages based on the newly increasedinterval). For example, the first network device may generate and send,after increasing the interval, a first DPD request message to the secondnetwork device via the IPsec tunnel based on the interval. The firstnetwork device then may receive a first DPD response message from thesecond network device via the IPsec tunnel based on sending the firstDPD request message.

In some implementations, the first network device may generate and send,after determining that the workload of the device satisfies the firstthreshold amount, one or more ESP packets (e.g., one or more ESP packetswith TFC payload data) to the second network device via the IPsectunnel. In some implementations, the second network device is able toidentify and discard the one or more such ESP packets upon receipt afterdecryption. In some implementations, the first network device maygenerate and send one or more ESP packets to the second network devicevia the IPsec tunnel using a data plane of the first network device. Inthis way, the first network device may minimize the amount of DPDrequest messages that the first network device receives from the secondnetwork device, which minimizes the amount of processing resources thefirst network device has to dedicate to DPD, by ensuring that traffic issent on the IPsec tunnel.

As shown by reference number 122, the first network device may determinethat the workload of the device satisfies a second threshold amount(e.g., a utilization rate of the first network device's resourcesdecreases to satisfy the second threshold amount, such as decreasingfrom 70% to 50%). In some implementations, the first network device maydecrease, based on determining that the workload of the first networkdevice satisfies the second threshold amount, the interval (e.g., thefirst network device may decrease the amount of time associated with theinterval, such as from 10 seconds to 5 seconds, from 50 seconds to 20seconds, from 6 minutes to 3 minutes, and/or the like). By decreasingthe interval because the workload of the network device is low, thenetwork device may be able to send and/or receive more DPD messages.

As shown by reference number 124, the first network device may sendand/or receive DPD messages according to the interval (e.g., the firstnetwork device may exchange DPD messages based on the newly decreasedinterval). For example, the first network device may generate and send,after decreasing the interval, a second DPD request message to thesecond network device via the IPsec tunnel based on the interval. Thefirst network device then may receive a second DPD response message fromthe second network device via the IPsec tunnel based on sending thesecond DPD request message.

In some implementations, the first network device may determine that theworkload of the first network device satisfies a third threshold amount(e.g., a utilization rate of the first network device's resourcesincreases to satisfy the third threshold amount, such as increasing from70% to 90%). In some implementations, because the workload of the firstnetwork device is high, the first network device may disable DPD at thefirst network device (e.g., to use processing resources that werededicated to DPD for other tasks) after the first network devicedetermines that the workload of the first network device satisfies thethird threshold amount in a similar manner as described herein inrelation to FIG. 1C. In some implementations, after the first networkdevice determines that the workload of the first network devicesatisfies the third threshold amount, the first network device maylisten for traffic on the IPsec tunnel and generate and send one or moreESP packets (e.g., one or ESP packets with TFC payload data) to thesecond network device via the IPsec tunnel in a similar manner asdescribed herein in relation to FIG. 1C.

In a third option, as shown in FIG. 1E, the first network device,regardless of the workload of the first network device, disables DPD atthe first network device and maintains the IPsec tunnel by generatingand sending one or more ESP messages (e.g., one or ESP packets with TFCpayload data) to the second network device via the IPsec tunnel as longas the first network device does not detect traffic on the IPsec tunnel.As shown by reference number 126, the first network device listens fortraffic on the IPsec tunnel in a similar manner as described herein inrelation to FIG. 1C. For example, the first network device may listenfor traffic on the IPsec tunnel during the interval. In someimplementations, the first network device may determine that there wasno traffic on the IPsec tunnel during the interval. For example, thefirst network device may determine that the first network device did notsend or receive information via the IPsec tunnel during the interval.

As shown by reference number 128, the first network device may generateand send one or more ESP packets (e.g., one or ESP packets with TFCpayload data) to the second network device via the IPsec tunnel whilethere is no traffic on the IPsec tunnel to maintain the IPsec tunnel. Insome implementations, the first network device may generate and send,based on determining that there is no traffic on the IPsec tunnel duringthe interval, one or more ESP packets (e.g., one or ESP packets with TFCpayload data) to the second network device via the IPsec tunnel. In someimplementations, the first network device may generate and send the oneor more ESP packets from a data plane of the first network device to thesecond network device via the IPsec tunnel.

As shown in FIG. 1F and by reference number 130, the one or more ESPpackets may include a protocol value that indicates that the one or moreESP packets are dummy packets. For example, a packet of the one or moreESP packets may include a protocol value of 59, e.g., a “Next Header”field with a value of 59, to designate the packet as a dummy packet.Upon receiving the one or more ESP packets, the second network mayidentify the one or more ESP packets as dummy packets, which causes thenetwork device to use minimal processing resources to discard the one ormore ESP packets. In some implementations, the packet may include a“Payload Data” field that includes TFC payload data. In someimplementations, the packet may include additional fields (e.g.,Security Parameter Index (SPI), Sequence Number, Padding, Pad Length, orIntegrity Check Value (ICV)). In some implementations, the one or moreESP packets are formatted to cause the second network device to discardthe one or more ESP packets upon receiving the one or more ESP packets.For example, the one or more ESP packets may include a protocol value of59 and Payload Data that includes plaintext that is not well-formed(e.g., the Payload Data includes random bytes). In some implementations,the one or more ESP packets are one or more dummy packets that arediscarded without prejudice by the second network device.

In this way, implementations described herein enable a network deviceand a peer network device to stay connected via an IPsec tunnel evenwhen the network device and/or the peer network device is overloaded. Inthis way, time is not wasted reinitiating IKE and IPsec negotiationsbetween the network device and the peer network device. Moreover, inthis way, a workload of the network device may be reduced because fewerprocessor and/or memory resources of the network device are used to keepthe IPsec tunnel active relative to a traditional DPD process.Furthermore, a process for maintaining IPsec tunnels is automated andthe network device may maintain numerous (e.g., hundreds, thousands,millions, and/or the like) IPsec tunnels at the same time. This mayimprove speed and efficiency of the process and conserve computingresources (e.g., processor resources, memory resources, and/or the like)of the network device. Furthermore, automating the process formaintaining IPsec tunnels conserves computing resources (e.g., processorresources, memory resources, and/or the like) that would otherwise bewasted using a traditional DPD process.

As indicated above, FIGS. 1A-1F are provided merely as examples. Otherexamples are possible and may differ from what was described with regardto FIGS. 1A-1F.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods, described herein, may be implemented. As shown in FIG.2, environment 200 may include a network device 210, a network device220, and a network 230. Devices of environment 200 may interconnect viawired connections, wireless connections, or a combination of wired andwireless connections.

Network device 210 includes one or more devices capable of receiving,storing, generating, processing, forwarding, and/or transferringinformation. For example, network device 210 may include a router, aswitch, a gateway, a firewall device, a modem, a hub, a bridge, anetwork interface controller (NIC), a reverse proxy, a server (e.g., aproxy server), a multiplexer, a security device, an intrusion detectiondevice, a load balancer, or a similar device. In some implementations,network device 210 may be a physical device implemented within ahousing, such as a chassis. In some implementations, network device 210may be a virtual device implemented by one or more computer devices of acloud computing environment or a data center. In some implementations,network device 210 may be an Internet Key Exchange (IKE) network device.

In some implementations, network device 210 may include variouscomponents, such as a data plane, a control plane, and/or the like. Insome implementations, the control plane of network device 210 runs anIKE server that handles IKE exchanges (e.g., information communicated onan IPsec tunnel, such as DPD request messages, DPD response messages,and/or the like). In some implementations, network device 210 mayidentify an IPsec tunnel that connects network device 210 to networkdevice 220. In some implementations, network device 210 may generate andsend a DPD request message to network device 220 via the IPsec tunnel,and may receive a DPD response message from network device 220 via theIPsec tunnel. In some implementations, network device 210 may receive aDPD request message from network device 220 via the IPsec tunnel, andmay generate and send a DPD response message to network device 220 viathe IPsec tunnel. In some implementations, network device 210 may listenfor traffic on the IPsec tunnel. In some implementations, network device210 may send and/or receive DPD messages according to an interval. Insome implementations, network device 210 may generate and send (e.g.,via the data plane of network device 210) one or more encapsulatingsecurity payload (ESP) packets (e.g., one or more ESP packets with TFCpayload data) to network device 220 via the IPsec tunnel.

Network device 220 includes one or more devices capable of receiving,storing, generating, processing, forwarding, and/or transferringinformation. For example, network device 220 may include a router, aswitch, a gateway, a firewall device, a modem, a hub, a bridge, anetwork interface controller (NIC), a reverse proxy, a server (e.g., aproxy server), a multiplexer, a security device, an intrusion detectiondevice, a load balancer, or a similar device. In some implementations,network device 220 may be a physical device implemented within ahousing, such as a chassis. In some implementations, network device 220may be a virtual device implemented by one or more computer devices of acloud computing environment or a data center. In some implementations,network device 220 may be an Internet Key Exchange (IKE) network device.

In some implementations, network device 220 may include variouscomponents, such as a data plane, a control plane, and/or the like. Insome implementations, the control plane of network device 220 runs anIKE server that handles IKE exchanges (e.g., information communicated onan IPsec tunnel, such as DPD request messages, DPD response messages,and/or the like). In some implementations, network device 220 mayidentify an IPsec tunnel that connects network device 210 to networkdevice 220. In some implementations, network device 220 may generate andsend a DPD request message to network device 210 via the IPsec tunnel,and may receive a DPD response message from network device 210 via theIPsec tunnel. In some implementations, network device 220 may receive aDPD request message from network device 210 via the IPsec tunnel, andmay generate and send a DPD response message to network device 210 viathe IPsec tunnel. In some implementations, network device 210 maygenerate and send and/or receive DPD messages according to an interval.In some implementations, network device 220 may receive (e.g., via thedata plane of network device 220) one or more encapsulating securitypayload (ESP) packets (e.g., one or more ESP packets with TFC payloaddata) from network device 210 via the IPsec tunnel.

Network 230 includes one or more wired and/or wireless networks. Forexample, network 230 may include a cellular network (e.g., a long-termevolution (LTE) network, a code division multiple access (CDMA) network,a 3G network, a 4G network, a 5G network, another type of nextgeneration network, etc.), a public land mobile network (PLMN), a localarea network (LAN), a wide area network (WAN), a metropolitan areanetwork (MAN), a telephone network (e.g., the Public Switched TelephoneNetwork (PSTN)), a communications network, a telecommunications network,a private network, an ad hoc network, an intranet, the Internet, a fiberoptic-based network, a cloud computing network, or the like, and/or acombination of these or other types of networks.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as an example. In practice, there may be additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseshown in FIG. 2. Furthermore, two or more devices shown in FIG. 2 may beimplemented within a single device, or a single device shown in FIG. 2may be implemented as multiple, distributed devices. Additionally, oralternatively, a set of devices (e.g., one or more devices) ofenvironment 200 may perform one or more functions described as beingperformed by another set of devices of environment 200.

FIG. 3 is a diagram of example components of a device 300. Device 300may correspond to network device 210 and/or network device 220. In someimplementations, network device 210 and/or network device 220 mayinclude one or more devices 300 and/or one or more components of device300. As shown in FIG. 3, device 300 may include a set of inputcomponents 305, a switching component 310, a set of output components315, and/or a controller 320. In some implementations, components ofdevices 300 may interconnect via wired connections, wirelessconnections, or a combination of wired and wireless connections.

Input component 305 may be a point of attachment for a physical linkconnected to device 300, and may be a point of entry for incomingtraffic (e.g., packets) received by device 300. Input component 305 mayprocess incoming traffic, such as by performing data link layerencapsulation or decapsulation. In some implementations, input component305 may send and/or receive packets. In some implementations, inputcomponent 305 may include an input line card that includes one or morepacket processing components (e.g., in the form of integrated circuits),such as one or more interface cards (IFCs), packet forwardingcomponents, line card controller components, input ports, processors,memories, and/or input queues.

Switching component 310 may interconnect input components 305 and outputcomponents 315. In some implementations, switching component 310 may beimplemented via one or more crossbars, via one or more busses, and/orusing shared memory. The shared memory may act as a temporary buffer tostore packets from input components 305 before the packets areeventually scheduled for delivery to output components 315. In someimplementations, switching component 310 may enable input components305, output components 315, and/or controller 320 to communicate.

Output component 315 may be a point of attachment for a physical linkconnected to device 300, and may be a point of exit for outgoing traffic(e.g., packets) transmitted by device 300. Output component 315 maystore packets and/or may schedule packets for transmission on outputphysical links. Output component 315 may support data link layerencapsulation or decapsulation, and/or a variety of higher-levelprotocols. In some implementations, output component 315 may sendpackets and/or receive packets. In some implementations, outputcomponent 315 may include an output line card that includes one or morepacket processing components (e.g., in the form of integrated circuits),such as one or more IFCs, packet forwarding components, line cardcontroller components, output ports, processors, memories, and/or outputqueues. In some implementations, input component 305 and outputcomponent 315 may be implemented by the same set of components (e.g., aninput/output component may be a combination of input component 305 andoutput component 315).

Controller 320 includes a processor in the form of, for example, acentral processing unit (CPU), a graphics processing unit (GPU), anaccelerated processing unit (APU), a microprocessor, a microcontroller,a digital signal processor (DSP), a field-programmable gate array(FPGA), an application-specific integrated circuit (ASIC), and/oranother type of processor that may interpret and/or executeinstructions. A processor is implemented in hardware, firmware, or acombination of hardware and software. In some implementations,controller 320 may include one or more processors that may be programmedto perform a function.

In some implementations, controller 320 may include a random accessmemory (RAM), a read only memory (ROM), and/or another type of dynamicor static storage device (e.g., a flash memory, a magnetic memory, anoptical memory, etc.) that stores information and/or instructions foruse by controller 320.

In some implementations, controller 320 may communicate with otherdevices, networks, and/or systems connected to device 300 to exchangeinformation regarding network topology. Controller 320 may createrouting tables based on the network topology information, may createforwarding tables based on the routing tables, and may forward theforwarding tables to input components 305 and/or output components 315.Input components 305 and/or output components 315 may use the forwardingtables to perform route lookups for incoming and/or outgoing packets.

Controller 320 may perform one or more processes described herein.Controller 320 may perform these processes in response to executingsoftware instructions stored by a non-transitory computer-readablemedium. A computer-readable medium is defined herein as a non-transitorymemory device. A memory device includes memory space within a singlephysical storage device or memory space spread across multiple physicalstorage devices.

Software instructions may be read into a memory and/or a storagecomponent associated with controller 320 from another computer-readablemedium or from another device via a communication interface. Whenexecuted, software instructions stored in a memory and/or a storagecomponent associated with controller 320 may cause controller 320 toperform one or more processes described herein. Additionally, oralternatively, hardwired circuitry may be used in place of or incombination with software instructions to perform one or more processesdescribed herein. Thus, implementations described herein are not limitedto any specific combination of hardware circuitry and software.

The number and arrangement of components shown in FIG. 3 are provided asan example. In practice, device 300 may include additional components,fewer components, different components, or differently arrangedcomponents than those shown in FIG. 3. Additionally, or alternatively, aset of components (e.g., one or more components) of device 300 mayperform one or more functions described as being performed by anotherset of components of device 300.

FIG. 4 is a flow chart of an example process 400 for maintainingInternet Protocol Security tunnels. In some implementations, one or moreprocess blocks of FIG. 4 may be performed by a network device (e.g.,network device 210). In some implementations, one or more process blocksof FIG. 4 may be performed by another device or a group of devicesseparate from or including the network device, such as another networkdevice (e.g., network device 220).

As shown in FIG. 4, process 400 may include identifying an InternetProtocol Security (IPsec) tunnel that connects the device to a remotedevice (block 410). For example, the network device (e.g., using inputcomponent 305, switching component 310, output component 315, controller320, and/or the like) may identify an IPsec tunnel that connects thedevice to a remote device, as described above in connection with FIGS.1A-1F.

As further shown in FIG. 4, process 400 may include determining thatdead peer detection (DPD) is enabled at the device (block 420). Forexample, the network device (e.g., using input component 305, switchingcomponent 310, output component 315, controller 320, and/or the like)may determine that DPD is enabled at the device, as described above inconnection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include receiving a firstDPD request message from the remote device via the IPsec tunnel (block430). For example, the network device (e.g., using input component 305,switching component 310, controller 320, and/or the like) may receive afirst DPD request message from the remote device via the IPsec tunnel,as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include sending a first DPDresponse message to the remote device via the IPsec tunnel (block 440).For example, the network device (e.g., using switching component 310,output component 315, controller 320, and/or the like) may send a firstDPD response message to the remote device via the IPsec tunnel, asdescribed above in connection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include determining that aworkload of the device satisfies a threshold amount (block 450). Forexample, the network device (e.g., using controller 320, and/or thelike) may determine that a workload of the device satisfies a thresholdamount, as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include sending, based ondetermining that the workload of the device satisfies the thresholdamount, one or more encapsulating security payload (ESP) packets thatinclude traffic flow confidentiality (TFC) payload data to the remotedevice via the IPsec tunnel (block 460). For example, the network device(e.g., using switching component 310, output component 315, controller320, and/or the like) may send, based on determining that the workloadof the device satisfies the threshold amount, one or more ESP packetsthat include traffic flow confidentiality (TFC) payload data to theremote device via the IPsec tunnel, as described above in connectionwith FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include determining, aftersending the one or more ESP packets, that the workload of the devicedoes not satisfy the threshold amount (block 470). For example, thenetwork device (e.g., using controller 320, and/or the like) maydetermine, after sending the one or more ESP packets, that the workloadof the device does not satisfy the threshold amount, as described abovein connection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include receiving a secondDPD request message from the remote device via the IPsec tunnel (block480). For example, the network device (e.g., using input component 305,switching component 310, controller 320, and/or the like) may receive asecond DPD request message from the remote device via the IPsec tunnel,as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 4, process 400 may include sending a second DPDresponse message to the remote device via the IPsec tunnel (block 490).For example, the network device (e.g., using switching component 310,output component 315, controller 320, and/or the like) may send a secondDPD response message to the remote device via the IPsec tunnel, asdescribed above in connection with FIGS. 1A-1F.

Process 400 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In some implementations, the network device may have a control plane,the network device may be to receive the first DPD request message andthe second DPD request message via the control plane, and the networkdevice may be to send the first DPD response message and the second DPDresponse message via the control plane. In some implementations, thenetwork device may have a data plane, and the network device may be tosend the one or more ESP packets via the data plane.

In some implementations, when sending, based on determining that theworkload of the network device satisfies the threshold amount, the oneor more ESP packets to the remote device via the IPsec tunnel, thenetwork device may identify a recurring interval associated with DPD,may determine a rate for sending the one or more ESP packets, where therate may be to ensure that at least one ESP packet of the one or moreESP packets is sent during the recurring interval, and may send the oneor more ESP packets to the remote device via the IPsec tunnel at therate.

In some implementations, the IPsec tunnel may be maintained while thenetwork device sends the one or more ESP packets to the remote devicevia the IPsec tunnel. In some implementations, the workload of thenetwork device may indicate a utilization of processing resourcesassociated with a control plane of the network device. In someimplementations, when determining that the workload of the devicesatisfies the threshold amount, the network device may determine thatthe utilization of processing resources associated with the controlplane of the device satisfies the threshold amount.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4. Additionally, or alternatively, two or more of theblocks of process 400 may be performed in parallel.

FIG. 5 is a flow chart of an example process 500 for maintainingInternet Protocol Security tunnels. In some implementations, one or moreprocess blocks of FIG. 5 may be performed by a network device (e.g.,network device 210). In some implementations, one or more process blocksof FIG. 5 may be performed by another device or a group of devicesseparate from or including the network device, such as another networkdevice (e.g., network device 220).

As shown in FIG. 5, process 500 may include identifying an InternetProtocol Security (IPsec) tunnel that connects the device to a remotedevice (block 510). For example, the network device (e.g., usingswitching component 310, output component 315, controller 320, and/orthe like) may identify an IPsec tunnel that connects the device to aremote device, as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 5, process 500 may include determining that adead peer detection (DPD) process is enabled at the device (block 520).For example, the network device (e.g., using switching component 310,output component 315, controller 320, and/or the like) may determinethat a DPD process is enabled at the device, as described above inconnection with FIGS. 1A-1F.

As further shown in FIG. 5, process 500 may include identifying arecurring interval associated with the DPD process (block 530). Forexample, the network device (e.g., using switching component 310, outputcomponent 315, controller 320, and/or the like) may identify a recurringinterval associated with the DPD process, as described above inconnection with FIGS. 1A-1F.

As further shown in FIG. 5, process 500 may include maintaining theIPsec tunnel, wherein, when maintaining the IPsec tunnel, process 500may include listening for traffic on the IPsec tunnel during therecurring interval, determining that there was no traffic on the IPsectunnel during the recurring interval, and sending, based on determiningthat there is no traffic on the IPsec tunnel during the recurringinterval, one or more encapsulating security payload (ESP) packets thatinclude traffic flow confidentiality (TFC) payload data to the remotedevice via the IPsec tunnel (block 540). For example, the network device(e.g., using switching component 310, output component 315, controller320, and/or the like) may maintain the IPsec tunnel, as described abovein connection with FIGS. 1A-1F. In some implementations, the networkdevice may listen for traffic on the IPsec tunnel during the recurringinterval, determine that there was no traffic on the IPsec tunnel duringthe recurring interval, and send, based on determining that there is notraffic on the IPsec tunnel during the recurring interval, one or moreESP packets that include traffic flow confidentiality (TFC) payload datato the remote device via the IPsec tunnel.

Process 500 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In some implementations, when sending, based on determining that thereis no traffic on the IPsec tunnel during the recurring interval, the oneor more ESP packets to the remote device via the IPsec tunnel, thenetwork device may send the one or more ESP packets from a data plane ofthe device to the remote device via the IPsec tunnel.

In some implementations, when listening for traffic on the IPsec tunnelduring the recurring interval, the network device may determine whetherthe device sends one or more outgoing messages to the remote device viathe IPsec tunnel during the recurring interval, and may determinewhether the device receives one or more incoming messages from theremote device via the IPsec tunnel during the recurring interval. Insome implementations, when determining that there was no traffic on theIPsec tunnel during the recurring interval, the network device maydetermine that the device did not send or receive information via theIPsec tunnel during the recurring interval.

In some implementations, the one or more ESP packets may include aprotocol value that indicates that the one or more ESP packets are dummypackets. In some implementations, the one or more ESP packets may beformatted to cause the remote device to discard the one or more ESPpackets upon receiving the one or more ESP packets. In someimplementations, the one or more ESP packets may include payload data,where the payload data includes plaintext that is not well-formed.

Although FIG. 5 shows example blocks of process 500, in someimplementations, process 500 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 5. Additionally, or alternatively, two or more of theblocks of process 500 may be performed in parallel.

FIG. 6 is a flow chart of an example process 600 for maintainingInternet Protocol Security tunnels. In some implementations, one or moreprocess blocks of FIG. 6 may be performed by a network device (e.g.,network device 210). In some implementations, one or more process blocksof FIG. 6 may be performed by another device or a group of devicesseparate from or including the network device, such as another networkdevice (e.g., network device 220).

As shown in FIG. 6, process 600 may include recognizing an InternetProtocol Security (IPsec) tunnel that connects the device to a remotedevice (block 605). For example, the network device (e.g., using inputcomponent 305, switching component 310, output component 315, controller320, and/or the like) may recognize an IPsec tunnel that connects thedevice to a remote device, as described above in connection with FIGS.1A-1F.

As further shown in FIG. 6, process 600 may include determining that thedevice uses dead peer detection (DPD) (block 610). For example, thenetwork device (e.g., using input component 305, switching component310, output component 315, controller 320, and/or the like) maydetermine that the device uses DPD, as described above in connectionwith FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include determining atrigger interval associated with DPD at the device (block 615). Forexample, the network device (e.g., using input component 305, switchingcomponent 310, output component 315, controller 320, and/or the like)may determine a trigger interval associated with DPD at the device, asdescribed above in connection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include determining that aworkload of the device satisfies a first threshold amount (block 620).For example, the network device (e.g., using controller 320, and/or thelike) may determine that a workload of the device satisfies a firstthreshold amount, as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include increasing, based ondetermining that the workload of the device satisfies the firstthreshold amount, the trigger interval (block 625). For example, thenetwork device (e.g., using input component 305, switching component310, output component 315, controller 320, and/or the like) mayincrease, based on determining that the workload of the device satisfiesthe first threshold amount, the trigger interval, as described above inconnection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include sending, afterincreasing the trigger interval, a first DPD request message to theremote device via the IPsec tunnel based on the trigger interval (block630). For example, the network device (e.g., using switching component310, output component 315, controller 320, and/or the like) may send,after increasing the trigger interval, a first DPD request message tothe remote device via the IPsec tunnel based on the trigger interval, asdescribed above in connection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include receiving a firstDPD response message from the remote device via the IPsec tunnel basedon sending the first DPD request message (block 635). For example, thenetwork device (e.g., using input component 305, switching component310, controller 320, and/or the like) may receive a first DPD responsemessage from the remote device via the IPsec tunnel based on sending thefirst DPD request message, as described above in connection with FIGS.1A-1F.

As further shown in FIG. 6, process 600 may include determining that theworkload of the device satisfies a second threshold amount (block 640).For example, the network device (e.g., using controller 320, and/or thelike) may determine that the workload of the device satisfies a secondthreshold amount, as described above in connection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include decreasing, based ondetermining that the workload of the device satisfies the secondthreshold amount, the trigger interval (block 645). For example, thenetwork device (e.g., using input component 305, switching component310, output component 315, controller 320, and/or the like) maydecrease, based on determining that the workload of the device satisfiesthe second threshold amount, the trigger interval, as described above inconnection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include sending, afterdecreasing the trigger interval, a second DPD request message to theremote device via the IPsec tunnel based on the trigger interval (block650). For example, the network device (e.g., using switching component310, output component 315, controller 320, and/or the like) may send,after decreasing the trigger interval, a second DPD request message tothe remote device via the IPsec tunnel based on the trigger interval, asdescribed above in connection with FIGS. 1A-1F.

As further shown in FIG. 6, process 600 may include receiving a secondDPD response message from the remote device via the IPsec tunnel basedon sending the second DPD request message (block 655). For example, thenetwork device (e.g., using input component 305, switching component310, output component 315, controller 320, and/or the like) may receivea second DPD response message from the remote device via the IPsectunnel based on sending the second DPD request message, as describedabove in connection with FIGS. 1A-1F.

Process 600 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In some implementations, the network device may send, after determiningthat the workload of the device satisfies the first threshold amount,one or more encapsulating security payload (ESP) packets to the remotedevice via the IPsec tunnel. In some implementations, the one or moreESP packets may be one or more dummy packets. In some implementations,when sending, after determining that the workload of the devicesatisfies the first threshold amount, the one or more ESP packets to theremote device via the IPsec tunnel, the network device may send the oneor more ESP packets to the remote device via the IPsec tunnel using adata plane of the device.

In some implementations, the workload of the device may indicate autilization rate of a control plane of the device. In someimplementations, when determining that the workload of the devicesatisfies the first threshold amount, the network device may determinethat the utilization rate of the control plane of the device satisfiesthe first threshold amount.

Although FIG. 6 shows example blocks of process 600, in someimplementations, process 600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 6. Additionally, or alternatively, two or more of theblocks of process 600 may be performed in parallel.

Some implementations described herein provide a network device 210 thatis capable of modifying DPD at network device 210 to maintain an IPsectunnel with a network device 220 while reducing a workload of processingresources associated with network device 210. In some implementations,network device 210 may determine that a workload of the network devicesatisfies a threshold amount and send one or more encapsulating securitypayload (ESP) packets to network device 220 via the IPsec tunnel. Insome implementations, network device 210 may determine that the workloadof the device satisfies a threshold amount and modify an intervalassociated with DPD at network device 210 to exchange DPD messages withnetwork device 220 according to the interval. In some implementations,network device 210 may disable DPD and send one or more ESP packets tonetwork device 220 via the IPsec tunnel.

In this way, implementations described herein enable network device 210and network device 220 to stay connected via the IPsec tunnel even whenthe network device or network device 220 is overloaded. In this way,time is not wasted reinitiating IKE and IPsec negotiations between thenetwork device and network device 220. Moreover, in this way, a workloadof network device 210 may be reduced because some implementationsrequire less use of processor and/or memory resources of network device210. Furthermore, a process for maintaining IPsec tunnels is automatedand network device 210 may maintain numerous (e.g., hundreds, thousands,millions, and/or the like) IPsec tunnels at the same time. This mayimprove speed and efficiency of the process and conserve computingresources (e.g., processor resources, memory resources, and/or the like)of network device 210 and/or network device 220. Furthermore, automatingthe process for maintaining IPsec tunnels conserves computing resources(e.g., processor resources, memory resources, and/or the like) ofnetwork device 210 and/or network device 220 that would otherwise bewasted using a traditional DPD process.

As used herein, the term traffic or content may include a set ofpackets. A packet may refer to a communication structure forcommunicating information, such as a protocol data unit (PDU), a networkpacket, a datagram, a segment, a message, a block, a cell, a frame, asubframe, a slot, a symbol, a portion of any of the above, and/oranother type of formatted or unformatted unit of data capable of beingtransmitted via a network.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or may be acquired from practice of theimplementations.

As used herein, the term component is intended to be broadly construedas hardware, firmware, and/or a combination of hardware and software.

Some implementations are described herein in connection with thresholds.As used herein, satisfying a threshold may refer to a value beinggreater than the threshold, more than the threshold, higher than thethreshold, greater than or equal to the threshold, less than thethreshold, fewer than the threshold, lower than the threshold, less thanor equal to the threshold, equal to the threshold, etc.

It will be apparent that systems and/or methods, described herein, maybe implemented in different forms of hardware, firmware, or acombination of hardware and software. The actual specialized controlhardware or software code used to implement these systems and/or methodsis not limiting of the implementations. Thus, the operation and behaviorof the systems and/or methods were described herein without reference tospecific software code—it being understood that software and hardwaremay be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of possible implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of possible implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items(e.g., related items, unrelated items, a combination of related andunrelated items, etc.), and may be used interchangeably with “one ormore.” Where only one item is intended, the term “one” or similarlanguage is used. Also, as used herein, the terms “has,” “have,”“having,” or the like are intended to be open-ended terms. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A method, comprising: identifying, by a device,an Internet Protocol Security (IPsec) tunnel that connects the device toa remote device; determining, by the device, that dead peer detection(DPD) is enabled at the device; receiving, by the device, a first DPDrequest message from the remote device via the IPsec tunnel; sending, bythe device, a first DPD response message to the remote device via theIPsec tunnel; determining, by the device, that a workload of the devicesatisfies a threshold amount; identifying, by the device, an intervalassociated with the DPD, the interval being an amount of time the remotedevice waits to generate and send a DPD request message after detectingidleness of the IPsec tunnel; determining, by the device, a rate to sendone or more encapsulating security payload (ESP) packets ensuring thatat least one ESP packet is generated and sent during the intervalmaintaining the IPsec tunnel while minimizing network resources of thedevice; sending, by the device and based on determining that theworkload of the device satisfies the threshold amount, the one or moreESP packets that include traffic flow confidentiality (TFC) payload datato the remote device via the IPsec tunnel based on the rate;determining, by the device and after sending the one or more ESPpackets, that the workload of the device does not satisfy the thresholdamount; receiving, by the device, a second DPD request message from theremote device via the IPsec tunnel; and sending, by the device, a secondDPD response message to the remote device via the IPsec tunnel.
 2. Themethod of claim 1, wherein the device has a control plane, wherein thedevice is to receive the first DPD request message and the second DPDrequest message via the control plane, and the device is to send thefirst DPD response message and the second DPD response message via thecontrol plane.
 3. The method of claim 2, wherein the device has a dataplane, wherein the device is to send the one or more ESP packets via thedata plane.
 4. The method of claim 1, wherein the IPsec tunnel ismaintained while the device sends the one or more ESP packets to theremote device via the IPsec tunnel.
 5. The method of claim 1, whereinthe workload of the device indicates a utilization of processingresources associated with a control plane of the device.
 6. The methodof claim 5, wherein determining that the workload of the devicesatisfies the threshold amount comprises: determining that theutilization of processing resources associated with the control plane ofthe device satisfies the threshold amount.
 7. The method of claim 1,wherein the device sends the one or more ESP packets to minimize anamount of DPD request messages that the device receives from the remotedevice.
 8. A non-transitory computer-readable medium storinginstructions, the instructions comprising: one or more instructionsthat, when executed by one or more processors of a device, cause the oneor more processors to: recognize an Internet Protocol Security (IPsec)tunnel that connects the device to a remote device; determine that thedevice uses dead peer detection (DPD); determine a trigger intervalassociated with DPD at the device, the trigger interval being an amountof time the remote device waits to generate and send a DPD requestmessage after detecting idleness of the IPsec tunnel; determine a rateto send DPD messages ensuring that at least one DPD message is generatedand sent during the trigger interval and that the IPsec tunnel ismaintained; determine that a workload of the device satisfies a firstthreshold amount; send, after determining that the workload of thedevice satisfies the first threshold amount, one or more encapsulatingsecurity payload (ESP) packets that include traffic flow confidentiality(TFC) payload data to the remote device via the IPsec tunnel; increase,based on determining that the workload of the device satisfies the firstthreshold amount, the trigger interval reducing the workload of thedevice; send, after increasing the trigger interval, a first DPD requestmessage to the remote device via the IPsec tunnel based on the triggerinterval; receive a first DPD response message from the remote devicevia the IPsec tunnel based on sending the first DPD request message;determine that the workload of the device satisfies a second thresholdamount; decrease, based on determining that the workload of the devicesatisfies the second threshold amount, the trigger interval; send, afterdecreasing the trigger interval, a second DPD request message to theremote device via the IPsec tunnel based on the trigger interval; andreceive a second DPD response message from the remote device via theIPsec tunnel based on sending the second DPD request message.
 9. Thenon-transitory computer-readable medium of claim 8, wherein the one ormore ESP packets are one or more dummy packets.
 10. The non-transitorycomputer-readable medium of claim 8, wherein the one or moreinstructions, that cause the one or more processors to send, afterdetermining that the workload of the device satisfies the firstthreshold amount, the one or more ESP packets to the remote device viathe IPsec tunnel, cause the one or more processors to: send the one ormore ESP packets to the remote device via the IPsec tunnel using a dataplane of the device.
 11. The non-transitory computer-readable medium ofclaim 8, wherein the workload of the device indicates the rate of acontrol plane of the device.
 12. The non-transitory computer-readablemedium of claim 11, wherein the one or more instructions, that cause theone or more processors to determine that the workload of the devicesatisfies the first threshold amount, cause the one or more processorsto: determine that the rate of the control plane of the device satisfiesthe first threshold amount.
 13. The non-transitory computer-readablemedium of claim 8, wherein the device sends the one or more ESP packetsto minimize an amount of DPD request messages that the device receivesfrom the remote device.
 14. A device, comprising: one or more memories;and one or more processors communicatively coupled to the one or morememories to: identify an Internet Protocol Security (IPsec) tunnel thatconnects the device to a remote device; determine that dead peerdetection (DPD) is enabled at the device; receive a first DPD requestmessage from the remote device via the IPsec tunnel; send a first DPDresponse message to the remote device via the IPsec tunnel; determinethat a workload of the device satisfies a threshold amount; identify aninterval associated with receiving one or more DPD request messages, theinterval being an amount of time the remote device waits to generate andsend a DPD request message after detecting idleness of the IPsec tunnel;determine a rate to send one or more encapsulating security payload(ESP) packets ensuring that at least one ESP packet is generated andsent during the interval maintaining the IPsec tunnel while minimizingnetwork resources of the device; send, based on determining that theworkload of the device satisfies the threshold amount, the one or moreESP packets that include traffic flow confidentiality (TFC) payload datato the remote device via the IPsec tunnel based on the rate; determine,after sending the one or more ESP packets, that the workload of thedevice does not satisfy the threshold amount; receive a second DPDrequest message from the remote device via the IPsec tunnel; and send asecond DPD response message to the remote device via the IPsec tunnel.15. The device of claim 14, wherein the device has a control plane,wherein the device is to receive the first DPD request message and thesecond DPD request message via the control plane, and the device is tosend the first DPD response message and the second DPD response messagevia the control plane.
 16. The device of claim 15, wherein the devicehas a data plane, and wherein the device is to send the one or more ESPpackets via the data plane.
 17. The device of claim 14, wherein theIPsec tunnel is maintained while the device sends the one or more ESPpackets to the remote device via the IPsec tunnel.
 18. The device ofclaim 14, wherein the workload of the device indicates a utilization ofprocessing resources associated with a control plane of the device. 19.The device of claim 18, wherein the one or more processors whendetermining that the workload of the device satisfies the thresholdamount are to: determine that the utilization of processing resourcesassociated with the control plane of the device satisfies the thresholdamount.
 20. The device of claim 14, wherein the device sends the one ormore ESP packets to minimize an amount of DPD request messages that thedevice receives from the remote device.